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Abstract 


We propose an approach for testing and validating message centric specifications. 
Testing is based on use cases, and does not attempt exhaustive testing. Messages 
contain pre- and post- conditions, based on which an object sends or receives a 
message. These conditions represent, the state of an object. An object will not send 
a message till the precondition is satisfied. Similarly an object will not receive a 
message till the postcondition, associated with the message, is satisfied. 

We test the system and generate test cases for the system, using these pre- and 
post- conditions. Testing and test case generation is done in two steps. Firstly, 
all.' use cases are generated. During which a table is formed, where all messages 
associated with a particular class is stored under that class. Secondly testing is 
done and test cases generated by considering the pre- and post-condition of all 
messages for a particular use case. These test cases can then be used to validate the 
system so developed. 
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Chapter 1 


INTRODUCTION 


1.1 Statement of problem 

There are many methodologies using which large and complex software can be built. 
Out of these methodologies object oriented methodologies are quite effective in man- 
aging such large and complex software. In a system which is built using the 00 
approach, static structure of the software is described by the object model. These 
objects then interact with each other to implement the system. 

A message based specification system for the object oriented software was devel- 
oped [Sar96], which effectively captures the dynamics of the system using a formal 
notation. In message centric specification system, the objects of the object model 
send messages amongst themselves to implement the functionality of the system. 
These messages constitute the message model of the system, which captures the dy- 
namics of the system. In the message model we have the pre- and post- conditions, 
which lay down constraints on the state of the objects. 

Precondition is the condition on the state of the sender before sending the mes- 
sage. Thus, an object will not send a message till the condition is satisfied. Simi- 
larly, a postcondition is the condition on the state of the receiver before receiving 
the message. Hence, an object (receiver) will not receive a message till postcondition 
is satisfied. For example in a usecase, class DOAA sends the message “give_rule” 
to class RULE-BOOK. The precondition of this message is that DOAA class (i.e. 
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the sender class, as the precondition is associated with the sender class) should 
have received “result_of_compute_cpi”. So till the time DO A A class does not re- 
ceive result_of_compute_cpi, it will not send the message “give_rule” to the class 
RULEJBOOK. Once the DOAA class receives the result_of_compute_cpi, it will send 
the message “give_rule” to class RULE-BOOK. 

In this thesis we propose an approach to testing and testcase generation using 
these pre- and post- conditions. We would be checking for inconsistency in the 
specifications (for the system being developed using the message centric specification 
system) and also generating testcases. If we try to generate testcases for all possible 
messages an object will send or receive, then it would become intractable. Hence, 
we try to generate testcases based on the usecases. Thus only those messages, which 
axe used in the usecase will be used for generating the testcases. This would limit 
our scope for generating the testcases. 

We are using usecases for testing and generating the testcases. A usecase is full 
trace of one complete interaction between a user and the sj'^stem. Thus all usecases 
together represent the various ways in which a user will use the system or interact 
with the system. Hence usecase based testing and testcase generation is the basic 
aim of our thesis. 

Our problem is, therefore, testing and generating testcases for a system (built 
using message centric specification system), which is based on usecases only. An 
object may send/ receive many messages, but only those messages which figure in 
usecases are used for testing and testcase generation. This helps in saving : 

• programmer time 

• effort 

• machine time 

• economy of the project 
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1.2 Testing 


In softwaxe construction, errors can be introduced at any stage during development. 
Generally the errors in specification and design are difficult to detect. These errors 
are reflected in the code. Since code is the only executable part of software whose 
behaviour can be observed, testing of software removes the errors remaining from 
earlier pha.ses. Testing is crucial for ensuring quality and reliability of the software. 
During testing, the program to be tested is executed with a set of testcases and 
the output of the program for testcases is evaluated to determine if the program is 
performing as it is expected to. 

Test activity is divided into verification and validation. Our thesis concerns 
validating the system. Testing object oriented software can be carried out at various 
levels. Unit testing is the lowest level of testing and is normally done by the developer 
himself. Unit tests are performed for classes, blocks and service packages. The next 
level of testing involves integration testing. The purpose of integration testing is 
to test whether the different units that have been developed are working together 
properly. It is performed by testing usecases one at a time, both from internal and 
external viewpoint. By external viewpoint we mean the interaction between the 
user and the system. And by internal viewpoint we mean the interaction amongst 
the various units/modules of the system. Each usecase then corresponds to a set of 
specifications. Finally in system testing, when all usecases have been tested properly, 
the entire system is tested as a whole, i.e. all the usecases are assumed to be running 
in parallel to check for the proper functioning of the system. 


1.3 Testing in a message based specification sys- 
tems 

In a message based specification system, the message model consists of precon- 
ditions and postconditions. The conditions are constraints on the state of the 
sender/receiver class before sending/receiving messages. These condition are useful 
in testing purpose. As these conditions are constraint on the state of the object. 
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these constraints would then act as testcases for the object for a particular usecase. 
Once testing and testcase generation is completed the system can be validated. Val- 
idation is part of the testing, wherein we check whether the system has been built as 
per the specifications. In our thesis, during testing we are checking for inconsistency 
in the specification and testcases can be used to determine the correct functioning 
of the system. However, validation is a different process in itself and is not dealt 
with in our thesis. 


1.4 Overview of thesis 

In this thesis we present a tool to generate testcases from the pre- and post- condition 
of the message model, based on the particular usecase. Our tool can be used for 
validation of the software, which other testing process do not do. 

The rest of the thesis is organized as : Chap 2 gives an introduction to the 
message based specification system. It basically gives the notation used and the 
process to be followed to arrive at the model. Chap 3 describes the design of the 
testcase generator. Chap 4 describes the implementation details where only the 
important structures have been described. Chap 5 gives the concluding remarks 
and possible extension. Appendix A gives the pseudocode for usecase and testcase 
generation. Appendix B gives an example of DOAA office automation which includes 
registration process, evaluation process and academic probation process. 
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Chapter 2 

Extension of previous work 


In this chapter we describe in brief the concept used in message based specification 
system, the notation used, and the development process in brief. Also described 
here is the on going work on the rapid prototyping tool for message centric based 
specification system. The description given here is very brief, for details refer to the 
original thesis [Sar96]. 


2.1 About message based specification system 

In this method the system is viewed as a collection of objects communicating with 
each other. Each object has some data that constitute its state and some rules that 
tell when to send a message, when to receive a message and what to do when a 
message is received . As all these rules involve messages, the rules are specified with 
the message rather than with the object. 

Below, we explain the terms that are used in this method are explained. 

Object An Object is an abstract or real world entity which has state, behavior and 
identity, and communicates with other objects. 

Most of the 0-0 methodologies give too much importance to the autonomous 
nature of an object that make the object an isolated entity. An object has both 
autonomous characteristics and interdependent characteristics. The attributes 
of an object are autonomous to it, i.e. depends on the nature of the objects. 
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But the state of the object depends on the interaction with other objects. As 
faj a5 the software systems are concerned, objects do not exist in isolation. 

State The state of an object at any instant consists of its knowledge about itself 
and its knowledge about the environment at that instant. 

The knowledge about itself is represented by the values of the attributes of that 
object. The knowledge about the environment is represented by the messages 
it transacts. 

Message A message forms the unit of communication between two objects. 

The message is defined by the sender, receiver, message identifier and the 
arguments for the message. Also specified along with the message are Pre 
conditions (Constraints on the state of the sender to send the message), Post 
conditions (Constraints on the state of the receiver to receive the message) 
and Action to be performed by the receiver on receiving that message. 

Process A Process is a sequence of events that happen to capture a meaningful 
real-world functionality. 

Processes and objects are two central concepts of this method. In the first 
stage (requirements specification) there will be only processes but no classes 
or objects. In Analysis and Design stages there will be both classes, objects 
and processes. And in the implementation there will be only objects but no 
processes. 

In requirements specification, processes are represented by plain English sen- 
tences. In Analysis and Design stages processes are represented in terms of 
messages and sub-processes, which again are represented in terms of messages. 

Generic process and Generic message Generic process is the mechanism by 
which we can represent similar turn of events once and reuse it later. Similarly 
generic messages can be used when similar messages are being sent to different 
objects. 
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Sub process Sub process specification is useful to handle complexity. Large pro- 
cesses can be decomposed into sub processes. Generally, if there is one central 
object that interacts with several objects to realize an operation then we put 
these interactions into a sub process. 

Usecase Usecase is a specific way of using the system by performing some parts 
of the functionality. Its a special sequence of related transactions performed 
by an user and the system in dialogue. Thus a complete collection of usecase 
would specify all the existing ways of using the system. 

2.1.1 Notation 

Object model 

The object model is used to represent the static structure of the system. There 
are three kinds of objects in the system :entity objects, interface objects and control 
objects. Entity or data objects are used to store information. They usually exist in 
the problem domain and represent some real-world entity or concept. Interface ob- 
jects are used to view data in entity objects. Control objects are used to collaborate 
between several entity and interface objects. The notation for entity and control 
objects is same and is different from notation for interface objects. 

Class Specification This specification is valid for entity and control objects. 
CLASS : Name of the class. 

Name of the class is an identifier. Syntactically, an identifier begins with a 
letter [a-zA-Z] and contains any alphanumeric character (including This 
declaration begins declaration of a new class. All the items that follow this 
declaration are assumed to belong to this class. Only another “CLASS : xxx” 
or end-of-file will end the declaration of this class. 

TYPE : ABSTRACT 

This field is optional, if nothing is specified about the TYPE, then it will be 
taken as non-abstract data class. An abstract class is one which Viaw 
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any instance. A class can be an abstract class only if it is a base class of an 
inheritance hierarchy. 

INHERITS : class name [, class name s] 

The list of classes from which this class inherits. 

ATTR : attr name <type> , attr_name <type> 

list of attributes each specified as attribute-name <type>. type can be any of 
the following : 

• STRING, NUMBER, DATE., etc. (i.e. scalar type) 

• attr-decl (represents list) 

• TABLE attributes list (a table) 

• attributes Jist ( set of dissimilar but related items) 

GENERALIZATION OF : class-name , class-name, ... 
class_name are classes which inherit this class. 

AGGREGATION OF : 

Class name (multiplicity) . 

PART OF : Class name (multiplicity) 

Multiplicity is the number of part of objects of the given class in the aggregate 
object . Note that multiplicity and class names are specified for part-of objects 
also. This means that there can be shared aggregation. 

For example. Department is collection of N number of system, N number of 
faculty members etc.. Student will belong to only one department, but a 
faculty member may belong to more than one department. Hence for student 
multiplicity is 1, and for the faculty member it is N. 

CLASS : STUDENT 

GENERALIZATION OF : UG-STUDENT 
CLASS : DEPARTMENT 

AGGREGATION OF : STUDENT (N), FACULTY (N) 
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CLASS : STUDENT 

PART OF : DEPARTMENT (1) 

CLASS : FACULTY 

PART OF : DEPARTMENT (N) 

RELATED WITH ; 

Related Class name (relation-name, multiplicity) Relation-name is the role the 
related object plays with respect to this object in the relation. Multiplicity 
specifies how many instances of the Related Class are related with one instance 
of this class. 

Interface object specification CLASS NAME : Name of the interface class 
TYPE : INTERFACE 
MENU ITEMS : 

id ; “menuJdentifier” name : “name of the menu” action : Action to be taken 
when this menu item is selected description : help message 

MenuJdentifier is used to uniquely identify this menu item. In addition to 
normal identifier syntax, “/” symbol can be used to denote the hierarchy of 
menu items. Name is the name of the menu item in more detail. This name 
is displayed to the user. Description is the message to be displayed when the 
user asks for help about this menu item. 

Action will be one of 

• send message msgJd [of processed [to object]] 

• do sub -process subprocJd 

• invokejnenu menuJd 

• select menuJtem 

• select fill Jn Jtem 

The actions axe explained in Message specifications. 
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Fillin items are generally used to represent data in forms and to take some 
temporary input data. 

DISPLAY METHOD : These are used to specify logical display of screen with 
fillin and menu items. 

INHERITS : 

GENERALIZATION OF : 

Semantics of inheritance for interface classes differs slightly from that for nor- 
mal classes. If interface class A inherits from interface class B, then A can 
use or replace some or all fill in items and display methods of B, and can also 
extend those menu items of B whose “actions” are invoke_menus. 

RELATED WITH : CLASS (relation, multiplicity) 

This has the same semantics as in normal class definitions. CLASS in RE- 
LATED WITH is used to declare which classes the interface object needs to 
attach to its fillJn items. 

Message model 
PROCESS: process-name 
SUB PROCESS :: sub_process_name. 

we divide something into sub processes when there is a central object that is 
gathering data from several objects to do certain operations. 

GENERIC SUB PROCESS :: generic_sub_process (parameters) 

INPUTS : parameters_varying_for_generic-sub_process. 

The declaration of a set of messages begins with one of the above three process, 
sub process or generic sub process declarations. 

FROM : Class name. 

TO : Class name (constraint). Class name is the name of the class specified 
in the object model. Constraint can be 

• condition on some attribute of the object. This is used to identify par- 
ticular instance of the class. 
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• variable = class-attribute class: tattributel = class ::attribute2 

• ALL, meaning all the instances of the class should be used for the purpose. 

• ALLJR.ELATED, meaning all the instances receiver class related to this 
object. 

HANDLE == ref 
HANDLE == BACK 

The above means that we explicitly give the handle. The handle identifies an 
object in the system. Every object will have an unique handle. In the context 
of a Database, handle is the primary key. When the handle is BACK, this 
means that the sender should not pick up the object handle from its Relations 
table, but should just send it, as a response to the message it received, to the 
corresponding object. 

MSGJD : message identifier (parameters). 

The syntax of message identifier is same as that of class name in Class specifica- 
tion. The syntax of the parameters is the same as syntax of “list of attributes” 
as described in the Class specifications. 

MSG_TYPE : type of the message. 

Type of the message can be reply, shared or exclusive. Reply means the mes- 
sage is being sent as a reply to a message this object has previously received. 
The sender of the request message expects and waits for this reply message. 
Shared and Exclusive represent the security level of the message. If it is spec- 
ified as exclusive, then only this object can send the message to the receiver. 
If it is specified as shared, then other objects can send this message to the 
receiver only if security level in that message specification is also specified as 
shared, shared is useful to restrict the senders to a set of objects. 

MSG_COND : 

Constraint that does not depend on the state of the sender, to send the mes- 
sage. This is used to send a message repeatedly (looping of the message) or 
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send a message depending on some condition which is not associated with the 
state of the object. For reasons of clarity, these message conditions surround 
the entire thread of messages which are invoked in a sequence as a result of 
issuing this message. 

RESULT: reply to this message 

The syntax of result is similar to that of list of attributes. When you specify 
the result , it means that the sender '^expects” some response to this message. 
This response is the result of action taken by the receiver of the message. 

PRE_COND : condition on the state of the sender before sending the message 

POST_COND : condition on the state of the receiver before receiving the 
message 

It is the combination (and/or) of one or more of the following things. 

• received msgJd [of processed] 

• received result_of msg id [of processid] 

• sent msgJd [of processid] 

• attribute = value 

• attributel = attribute2 

The Pre condition is a constraint on the state of the sender to send the mes- 
sage. Post condition is a constraint on the state of the receiver to receive 
the message. By specifying different Post conditions for the same message ex- 
changed between same two objects, we can have different actions depending on 
when the message is received. Other use of Post condition is to decide whether 
to accept or reject the message depending on its time of arrival. While coding, 
Pre condition is generally useful to position the function call. Pre and Post 
conditions are also important for testing purposes. 

ACTION: action to be taken after this message has been received 
Action can be any of the following 
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• send message msgid [of processud] 

For example, class STUDENT.INTERFACE sends the message “get_reg_form” 
to class STUDENT. The action associated with this message is send mes- 
sage “reqTor jreg-form” . 

• do sub-process sub_procJd (parameters) 

For example, class DOAA send message “notice_for_registration” to class 

• send generic message msgJd 

Generic message as described earlier are similar messages sent to different 
objects. 

• do generic sub-process processed (parameters) 

For example, class DOA A JNTERFACE sends message “prepare_reg_notice” 
to class DOAA. The action associated with this message is to do generic 
subprocess “make_notice” . 

• select menuJtem xxx 

For example, class DOAAJNTERFACE has two menu items under the 

menu id grades. These menu items are prepare_grades_sheets and send^rade_sheets. 

We select a particular menu item by this action. 

“select menuJtem xxx” can be used only if the receiver is an Interface 
object. 

GENERIC MESSAGE: 

declaration of normal message, except that some fields will be empty. 

VARIABLES IN MESSAGE 

To specify the source of a variable (an argument to the Message or a variable 
in a PRE-COND etc.), we use the following : 

• an attribute of sender variable. 

• Sender receives it as an argument of some other message of this pro- 
cesslmsgJdlvariable . 
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modeled in the past. This is very important particularly if we want to make 
re-use of design and code. 

Initial object model 

There are two kinds of identification in this method (be it identifying objects, 
attributes or messages). Identifying by intuition and identifying when nec- 
essary. When looking at a system, one can intuitively capture some obvious 
paxts of the system. We represent these parts of the system in the Initial ob- 
ject domain model. Also, having some essential objects helps in starting with 
the message model. 

In the initial object model, all the possible “obvious” classes, structures, at- 
tributes and services will be specified. Note that this need not be a compre- 
hensive list of all objects in the system. Even if some are missed, they will be 
captured while specifying the message model. 

We can’ specify the trivial interface objects also at this stage itself. These 
are interfaces corresponding to the human users of the end-system. Every 
possible user (generally roles with respect to the system) needs an interface to 
the system. 

Analyze the Processes (Building message model and refining object model) 

Specify each process as a sequence of messages. In the best case, each sentence 
in the process description can be translated into a message. Initially it is 
better to start with the simplest specification of a message : Sender, receiver 
and messageJd. Because here we do not assume that process descriptions 
(given in the requirements specification phase) are unchangeable. As we can 
generate graphical feed-back even from this simple specification, it may help 
to correct requirements specification at an early stage. This (correction) does 
not cause any problem because the traceability between process descriptions 
and the initial message model is very high. 

You may need to add some more objects to the system as the need arises 
while converting a process to messages. So, this will lead to discovery of 
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more objects (Application specific) and attributes. The two activities in this 
phase, identifying objects and identifying messages, are very much interleaved 
and interdependent. We can not specify any particular order regarding which, 
activity is to be done first and which activity is to be done next. That is why 
both the activities are put in a single phase. 

Message model and object model complement each other in system develop- 
ment. One may find that more objects are required to model the messages 
generated by processes/sub processes. This will add objects to the object 
model, thereby refining the object model. The new objects may help to refine 
the message model (by re-defining the boundaries of the messages). 

Refining message model 

Specify each message in more detail, i.e. giving Pre conditions, Post condi- 
tions, constraints etc. The message should be completely defined so that we 
identify its position (in control flow) independent of other messages. 

Merging of Analysis models of Various processes 

If there is division of labour in the analysis, i.e. if different sets of processes 
are analized by different groups of personnel, then there are bound to be some 
common objects and attributes that are discovered by more than one group. 
So, these have to be merged to form a single representation for the object 
model, and any inconsistencies have to be resolved. It is better to coordinate 
among the groups whenever there is a change to the object model as the 
modifications to the message models will be easy initially. 

Design 

In the Analysis, we describe what is to be done in the system. In the Design, 
we show how it is to be done. This “how” corresponds to the Implementation 
domain but not the problem domain. 

In design we need not add any extra objects or messages to the specifications. 
We have to decide how to implement various components of the analysis mod- 
els. Typically there are two phases of design. Designing at Macro level and 
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Designing at micro level. 

Designing at macro level involves deciding overall architecture of the system 
: whether it has to be distributed or monolithic, if it is distributed, dividing 
the object model into Sub systems and allocating sub systems to Computers. 

While designing at the micro level, we have to look at each object and see what 
all messages it receives and sends, and specifying algorithms for its private 
methods (generally “self” messages in the message model). Also, design a 
mechanism for storing and retrieving transient data that is sent along with 
messages. 


2.2 Rapid prototyping for message centric based 
specification system 

The rapid prototyping tool is a tool for executing the requirement specification as 
given by the user. It reads the requirement specification, and executes the system 
according to the specs. Thus enabling the user to only input the requirement specs 
and check the system being run. This tool haa the following components ; - 

• Symbol table manager (STM) 

• Interpreter 

• Persistence manager 

Out of, these components only the STM is relevant to our thesis, hence it is described 
in brief here. For more details and other components refer [Sri97] M.Tech thesis “A 
rapid prototyping tool for message centric specification system” which is being done 
concurrently. 

2.2.1 Symbol table manager (STM) 

The STM is the front end portion of the tool. It reads the x'equirement specification, 
parses it and creates and maintains tables. These tables consist of all the classes. 
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their attributes, functions, messages and their details. Once the STM is created, 
it is referred to and the details extracted during usecase generation portion of the 
testing and testcase generation. Description of how the STM is used during usecase 
generation is described in the next chapter. 
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Chapter 3 
Design 


In this chapter is described how the testcases are generated from the requirement 
specifications. The symbol table manager parses the requirement specification and 
maintains a table which has all the objects and messages passed amongst them. 
We use this symbol table manager in usecase generation, extensively. Testing and 
testcase generation is divided into two parts:- 

• usecase generation 

• testcases 

In usecase generation we start from an interface class (these classes have menu 
items). Each menu item is taken as a starting point of a separate usecase. These 
menu items have aji action field which may be of the type send message. We extract 
the message id of this send message and lookup in the STM. Once a match is found, 
the action field of the found message is again checked. If its again of the type send 
message, the process of extracting message id, looking up in STM and finding a 
match is performed. Thus creating a sequence of message starting from a menu 
item. The usecase is complete when the message found in STM has no action field. 
(Refer figure for clarity) 

In testing and testcase generation, we take each usecase. During usecase gener- 
ation all messages being sent or received by a class is stored under that class. As 
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Figure 1 : Creating usecase as sequence of messages 
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Figure 2: Example of a iisecase 


usecase is stored as linked list of messages, each message of the usecase under con- 
sideration is taken. And the pre- and post- condition of these messages are checked 
and testcases generated for this usecase, for the particular class. 


3.1 Usecase generation 

A usecase is full trace of one complete interaction between a user and the system. 
For example in DOAA office automation let us consider a usecase in evaluation 
process. The user selects the menu item send-grade_sheets to class STUDENT. The 
class STUDENT in response to this message stores the grade_sheets. Thus, in this 
usecase, the grade sheet is being given by the DOAA to the STUDENT. Thus, in a 
message based specification system we take the interface class as the starting point, 
as these axe the classes the user uses to interact with the system. A tree traversal 
algorithm is used to access each and every menu item of the interface class. 

Each interface class has a menu item field which identifies the name of the menu 
item and action field which describe the action to be taken when that particular 
menu item is chosen. We have considered each menu item to be a separate usecase. 
Thus each traversal through the menu tree to a menu item gives a separate usecase. 
Based on the type of action various usecase are generated. The different action are:- 


• send message 

• do sub process 
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• invoke menu item 


• select fill in 

An interface class consists of fill in itenis, apart from the menu items. These fill in 
items are invoked by select fill in type of action of menu item. 

3.1.1 Send message 

When the action of the menu item selected is to send a message of a particular 
process then the message is looked for in the symbol table manager. If the same 
message is not found, then the usecase is terminated there itself. For example, in 
the interface class DOAAJNTERFCAE there is a menu item “grades”. This menu 
item has action to invoke another menu. The menu’s invoked are 

• prepare_grade_sheet 

• send_grade_sheet_to_dept 

We consider prepare_grade_sheet. The action field of this menu item is to send a 
message “prepare^radejsheets of evaluation process”. We extract the message id 
prepare_grade_sheet of the evaluation process. And lookup the STM for this mes- 
sage prepare..grade_sheet, and process as evaluation process. We find the message 
prepare-gradejheet in STM. We then extract the following 

• sender class DOAA JNTERFACE 

• receiver class DOAA 

• action field do_sub_process_prepare_grade^heet 

In case the message prepare_grade_sheet is not found in the STM, then there is an 
error in the specification. (This case has not been fully specified and hence is flagged 
as consistency error). 

However the action here is to do a subprocess. So the subprocess id “pre- 
pare_gradejsheet” is extracted. All messages pertaining to this subprocess is stored 
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in STM, as a linked list. This linked list of messages constitute a part of the use- 
case. For each message, the message id is stored under the sender class and the 
receiver class. Within the class the messages are again stored as a linked list of mes- 
sages. This is done because during testcase generation, the pre- and post-condition 
which restrict values of an attribute of classes are extracted from the messages of 
the usecase. 

The message structure is stored under the sender class and the receiver class. 
The message structure is modified to point to the next message in the same usecase. 
Thus the message in the sender class points to the copy of the message stored under 
the receiver class. The receiver class message then points to the next message in the 
same usecase. 

The action field of the message can then again be of the following type:- 

• send message 

• do subprocess (explained in example above) 

• perform some action and stop 

• there is no action field 

If the action is to send a message, then again we extract the message id and the 
message is searched in the symbol table manager, message is stored under the sender 
class and receiver class and pointer to the next message in the same usecase is 
assigned. This sequence is performed until either the action field is null or action 
is to do some task and stop. Thus a sequence of messages for the usecase is stored 
under the respective classes. 

If the action is to do a subprocess, then all the message sequences, stored under 
that subprocess in the symbol table manager, is taken and stored under respective 
classes and their pointers assigned accordingly. All messages of the usecase are 
connected by pointers, which point to the messages in the same usecase. Each 
usecase is given a unique usecase id. 

When the action of the message is to perform a task and then stop, then this 
is taken as a termination point of the usecase. This is because the task will not be 
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stored in the symbol table manager as a message. Thus even if a search in the STM 
is carried out with the task as the message id, no message will be found. The last 
message in the usecase will have its next message in the usecase point to NULL. 

Lastly when the action field of a message is missing then also its considered to 
be a termination of the usecase. 

All the messages that are stored under a clas's have one more pointer that points 
to the next message under that class. The next message may or may not belong to 
the same usecase. 

3.1.2 Do subprocess 

When the action of the menu item selected involves activating a subprocess then all 
messages relating to the subprocess are stored in the STM under this subprocess 
id. The subprocess may contain a sequence of messages, which may be stored in a 
loop or in an if-else condition. We get the message sequence for the if condition as 
well as for the else condition. In case the message sequence is stored in the loop 
again all messages are extracted and stored under respective classes (as in the send 
message process), and appropriate pointers assigned. A subprocess would constitute 
a usecase or a part of usecase. 

3.1.3 Invoke menu 

When the action of the menu item selected is to invoke a submenu or another menu, 
then another pull down menu is provided to the user. The user may then select any 
menu item which would then point to the start of a usecase ( provided the menu 
item selected is of the type send message or do subprocess or select fill in item. If 
the menu item again is of the type invoke menu then a menu is presented to the 
user once more). 

3.1.4 Invoke fill in 

P 

When the action of the menu item selected is to invoke a fill in item, then the blank 
fields of the interface class are displayed to the user, where the user is required to 
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fill in some details. Fill in item are generally used to represent data in forms and to 
take some temporary input data. This is ax:tually the interface through which the 
user is interacting with the system. 

3.1.5 Select menu item 

When the action of menu item is to select a menu item, the user selects a menu item 
from the menu displayed. Based on the menu item selected a usecase is generated 
or further a menu is presented or fill in interface is selected. 


3.2 Testcases 

Once a number of usecases for a particular interface class selected, are generated 
the same step is performed to get rest of the usecases for rest of the interface class. 
Each usecaae will have a unique usecase id which identifies the useacase. Also all the 
messages for a particular class axe stored under the class structure. A class will have 
a sequence of messages belonging to same or different usecase(s). All messages of a 
particular usecase would be linked accordingly. And all messages of a class would 
also be linked. 

Thus now to generate testcases, we check a particular usecase and traverse it. 
Since usecase is stored as a sequence of messages, we keep checking the messages 
for precondition and postcondition. And based on these pre- and post- condition 
we generate testcases. 

Precondition is the constraint on the state of the sender before sending a message 
and postcondition is the constraint on the state of the receiver before receiving the 
message. If a precondition is not satisfied then the sender will not send the message 
till the condition is satisfied. Similarly if a postcondition is not satisfied then the 
receiver will not receive the message till the condition is satisfied. 

The pre- and post-condition is a combination (and/or) of one of the following:- 


• received message id 

• received resultof message id 
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• done subprocess 

• constraints 

The first three type of conditions help in determining the consistency in the require- 
ment specification, whereas the fourth type of condition helps in determining the 
testcase. Each type of condition is dealt with separately. 

3.2.1 Received message id 

While traversing a usecase, we check the message for precondition and postcondition. 
In case the precondition is of the type received message id, then we extract the 
message id from the precondition. Also we extract the sender and the receiver class 
from the message structure. Now the sender (receiver in the postcondition) should 
have received this message before sending (receiving in postcondition) the message 
to the receiver (from the sender in postcondition). We then find the sender class 
(receiver class in postcondition) in the class base. Once the sender class is found, 
we traverse the messages stored under that class, during usecase generation. And 
try to find a message with the same message id as extracted from the precondition 
(postcondition). In case no match is found then this usecase is flagged as an error 
as the usecase may not be complete. 

In case message with the message id as extracted from the precondition is found, 
the usecase id of the found message is extracted. And then the usecase with this 
usecase id is traversed, till the message id as extracted from the precondition is 
encountered. If upto this message id no other message with a precondition (or 
postcondition) is encountered then we proceed ahead in our original usecase, in 
which we had encountered the last precondition. However in the found usecase id if 
there is another message with a precondition then the whole process of testcases is 
repeated. 

How then is the inconsistency in the requirement specification determined ? It 
is determined if in the found usecase , there is a precondition to receive a message, 
after the precondition in the original usecase. For example suppose we are traversing 
a usecase with usecase id 1. There is a message with precondition “received message 
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X” in. this usecase. We extract the message X from the precondition of usecase id 1. 
Also we extract the sender class and the receiver class. We then find the sender class 
in the class base. Once the sender class is found in the class base we search for the 
message X under this class. Suppose there is a message X under this class which has a 
usecase id 5. We then traverse the usecase id 5 from the beginning till the message id 
with message X is encountered in this usecase. Also suppose before encountering the 
message X, there is a message in usecase id 5 with a precondition “received message 
Y”. And this message appears in the usecase id 1 after the message with precondition 
“received message X”. Then there is an inconsistency in the specification, which has 
to be corrected. 

Similar procedure is adopted to find inconsistency arising out of the postcondi- 
tion. Thus the “received message” type of pre/post-condition is used to find the 
inconsistency in the requirement specification. 

3.2.2 Received resultof message 

In this type of precondition the sender class is waiting for some response from the 
recover class. The sender class must have asked the receiver class for some details. 
And before executing further, the sender should have received the response to its 
earlier message. Thus its concluded that the precondition is from the same usecase 
id. 

Thus again we extract the sender class, receiver class and the message id from 
the precondition. We then search the message under the sender class and the same 
usecase id as the original one. The usecase is then traversed now to find the message 
with message id given in the precondition before the precondition is encountered. 

In case the message is found, we proceed ahead with the last usecase being 
processed. In case the message is not found, then an error is flagged in that usecase. 
Thus detecting an inconsistency in the specification. 

Similarly inconsistency may be detected by checking the postconditions. 

For example in a usecase that we checked, class DOAA sends message give_rule to 
class RULEJBOOK. There is however a precondition received resultof_compute_cpi. 
We first extract the message id compute.cpi from this precondition. Then we extract 
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the sender class, i.e DOAA from the message. The class array is looked up for this 
class. And the pointer to the start of the message sequence stored under that class 
is taken. We then traverse, this message sequence of DOAA class till we get the 
message compute_cpi. 

Once the message is found we take its usecase id. And now traverse this new 
found usecase from beginning to the message with message id compute_cpi. We 
keep checking every message for pre- and post- condition and thus try to determine 
consistency or inconsistency in the system as outlined in the above section (i.e. 
3 . 2 . 1 ). * 

If the message is not found then there is an error in the specification. 

3.2.3 Done subprocess 

When the precondition encountered is of the type, done subprocess, then we conclude 
that this sender class should have received the message to do this subprocess earlier. 
Thus we extract the process id from the precondition and the sender class name. 
Then the messages under that sender class is checked in which this class is the 
receiver of the message “do subprocess” and the action field related to this message 
is of the type “do subprocess”. If no such message is found, then flag an error in 
the usecase. Else if usecase is same as that of the present usecase then proceed 
as in 3.2.2. If the usecase is different than the present usecase then proceed as in 
3.2.1 . Similarly we proceed in the case of postcondition. Thus inconsistency in the 
specification is determined. 

For example in a usecase that we tested for consistency, class DOAA sends 
message stud_grade_sheet to class DEPTT. The precondition is done sub.process 
prep_grade_sheet. We first extract the process id prep_grade_sheet from this precon- 
dition. Also we take the sender class, i.e. DOAA. And now lookup the class array 
for class DOAA. We get the pointer to message sequence stored under this class and 
traverse it. We look for a message in which the receiver of the message is this class 
(i.e DOAA class) and the action of the message is to do subprocess prep_grade_sheet. 

If the message is found then we proceed with the previous usecase. If the message 
is not found then then the previous usecase is flagged as INCORRECT. 
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3.2.4 Constraints 


In case the precondition is of the type constraint, then the various constraints are 
flashed to the user who then gives the input which satisfies all these constraints. 
Here the input from the user is treated as string and the data input by the user 
may or may not satisfy the constraint. In either case, the data input by the user is 
recorded as a testcase. The user will be prompted as to whether the constraints can 
be satisfied or not. In any case if the user inputs data whether correct or incorrect 
it will be stored as a testcase. 

Only the last type of precondition is actually used to generate the testcase di- 
rectly from the requirement specification. 

For example if there is a constraint that a student will be issued a warning letter 
if the SPI or the CPI at the end of the regular semester is 
2.0 < SPI <= 4.5 AND CPI > 4.5 

This constraint will be displayed to the user. And if there is any student who 
satisfies the above condition of SPI and CPI then the DOAA will issue message 
wajning to the student. However, the user is displayed only the constraints. The 
data filled by the user is treated as a string and stored as testcase. If there is a 
value which would satisfy the above constraints, then it is stored as correct testcase. 
Values not satisfying the constraint are stored as incorrect testcase. 
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Chapter 4 

Implementation 


In this chapter is described, the various structures, used and modified, to implement 
the testcase generator. But the ones that were modified are only described here. 
The structures have been defined and declared in the thesis being done currently. 


4.1 Use_CaseJVIsg 

This structure uses the basic structure of the message, as described in the “pioc.h” 
header file. The structure is as follows:- 

struct Use_Case_Msg Msg u_c_msg; int use_caseJd; Use_Case_Msg *next; Use_Case_Msg 
*nextnasg; ; 

The variable u_c_msg is of the type Msg, the basic structure of message. An 
integer use.caseJd defines the message belonging to a particular usecase uniquely. 
Pointer to data of the same type, points to the next message in the same usecase 
only. Also a pointer to the same data type again points to the next message in 
the same class. The testcase generator uses this structure to generate testcases and 
usecases. 
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4.2 newClass 


This structure is used to store all the classes appearing in the requirement specifi- 
cation. All classes are stored in an array of this new class structure. The newClass 
structure is as follows:- 

struct newClass Clas nclas; Use_Case_Msg *next; cls_array[]; 

The variable nclas is of the type Clas described in the “class.h” header file. As 
the individual class will have to point to sequences of messages a pointer to the data 
type Use_Case_Msg is also defined. Access to the messages associated under a class 
can be gained through this Use_Case_Msg pointer. This structure is initialized and 
filled during usecase generation, but is used extensively in testcase generation. 

4.3 Start _ptr_table 

All the usecases are stored in an array of structures called the start_ptr_table. The 
structure used to describe this table is as followst- 

struct Stat JPtr.Table Use_Case_Msg *start_ptr; Use_Case-msg *curr_msg_ptr; int 
status-flag; start_ptr_table; 

This table has a pointer to the first message in the usecase. Thus there is a 
pointer to data type Use_Case_Msg. The second pointer to the same data type 
keeps track of the message in the usecase upto which the usecase has been checked. 
The integer type of data to maintain the status of the usecase is used as follows 
0 usecase is uninitialized 1 usecase has been checked and is found correct 2 
usecase has been checked and is incorrect 3 usecase is being checked 


4.4 Implementation 

Initially the class array is initialized to null and the pointer to message is assigned 
to NULL. Then the start pointer table is initialized, wherein the curr-msg-ptr is 
assigned NULL and the status Jiag of all the usecase is set to 0. Then each interface 
class is taken and usecases are generated. Finally considering each usecase either 
inconsistency in requirement specification is reported or testcase is generated. 
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Chapter 5 

CONCLUSION 


5.1 Conclusion 

The complete implementation of the testcase generator was done in two steps. First, 
usecase generation module was tried. The examples taken were from DOAA office 
automation. As the complete specification would have been quite large, only regis- 
tration and evaluation process were taken as example. An interface class was taken 
and usecases generated, for the various menu items in this interface class. This 
process of usecase g(‘n(n'at.ian was t.hen incorporate<l for other interface classes. 

Secondly, testcase generation module was developed. Aim of this module was 
to determine the inconsistencies and to present the testcases to the user. The user 
would then have to store his input as testcases for testing the system. The user in 
this case is the developer of the system who can store correct or incorrect data as 
testcases to check for the correctness of the system being built. 


5.2 Results 

Usecases were generated for all the interface classes in DOAA office automation 
system (i.e registration and evaluation process). Only then testcases were generated 
and testing was done. The example taken lends itself for testing, i.e check for 
inconsistencies in the specification. Whenever at a particular message, the usecase 
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was found to be incorrect, the testing was not stopped. It was continued till the end 
of the usecase, which helps in determining the place where that usecase has failed. 

For generating the testcases separate example of academic probation was taken. 
When this tool was used on the academic probation process testcases were generated 
and prompted to the user. If there was a condition that satisfied the constraint, it 
was taken as a correct testcase. Values not satisfying the constraint were taken as 
incorrect testcases. 


5.3 Possible extensions 

1. This tool can be used to generate testcases (both correct and incorrect) auto- 
matically. 

2. Can also be used to validate the system being built, by running testcases being 
generated on the software being done. 
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Appendix A 
Pseudocodes 


A.l Pseudocode for usecase generation 


traverse_menii_tree(curr_memi_ptr) 

■c 

if (curr_menu_ptr -> action = invoke.menii) 
traverse_menu_tree(curr_menu_ptr -> down) ; 
else 
{ 

if (curr_menu_ptr -> action = send.msg) 

generate_usecase_id ; 
scan_the_sequence_of _messgae ; 

} 

else 

if (curr_menu_ptr -> action = do_sub_process) 

{ 

generate_usecase_id; 

get_all_messages_related_to+sub_process; 
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} 

else 


give_user_interface_to_user; 

} 

} 

if (cilrr_inenu_ptr -> next != NULL ) 
traverse_inenu_tree(curr_menu_ptr -> next) 


// scans the sequence of message 

scan_the_sequence_of .message (curr_menu_ptr) 

{ 

while (curr.menu.ptr -> action == send.msg) 

■C 

get_message_id(curr_menu_ptr) ; 

initialize_this_message_to_new_message_structure(msd_id) ; 
associate_this_message_to_appropriate_class (msg.id ) ; 

} 

} 


1 1 gets and associates all messages related to the subprocess 

get_all_messages_related_to_sub_process(curr_menu_ptr) 

{ 

while(no_more_messages_in.sub .process) 

{' 

get .next .msg. of. this. sub.process; 

initialize.this.message.to.new.message.structureCmsd.id) ; 
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associat e_tliis_message_to_appropriate_class (msg_id) ; 

} 

} 


A. 2 Pseudocode for testing and testcase genera- 

tion 

for_eacli_iisecase do 

{ 

traverse_usecase() ; 

while(starting_message != message_being_checked) 

■C 

switchCmessage -> precondiion) 
case RECD.MSG : 

seaLrch_sender_class_naiiie_iii_class_array; 
get_ptr_to_msg_seq_f or_this_class; 
traverse_this_msg_seq_for_msg_id_as_i]a_RECD_MSG; 
if (message.not .found) 

{ 

f lag_usecase_as_INCORRECT ; 
break; 

} 

else 

■c 

check.usecase.id.of _this_f ound.msg; 
check_status_flag_of_that_usecase; 
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switch(status_flag) 


case CORRECT : 

usecasel is.correct ; 
breads; 

case INCORRECT : 

f laLg_Tisecase_as_INCORRECT : 
breads; 

case BEING.CHECKED : 

check_for_found_nisg_in_this_usecase; 
if (f oimd) 
break; 
else 

f lag_usecase_as_INCORRECT ; 
breads; 

case UNINITIALIZED : 
traverse_usecase() ; 
break; 

} 

breads: 

} 

case RECD_RESULTOF_MSG : 

seaLrch_seiider_class_naine_in._class_array ; 
get_ptr_to_msg_seq_f or_this_class; 
extract _msd_ id_f rom_RECD_RESULTOF_MSG ; 

traverse„this_itisg_seq_f or_itisg_id_as_iii_RECD_RESULTOF_MSG ; 
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if (message.not .found) 

{ 

flag_usecase_as_INGORRECT; 

breeik; 

} 

else 

{ 

check_usecase_ id_ of _thi s_f ound.msg ; 
check.f ound_msg_ in.usecase ; 
if (found) 
break; 
else 

■c 

f laig.usecase.as.INCORRECT ; 
break; 

} 

} 

break; 

case DONE_SUB_PROCESS : 

search_sender_class_name_in_class_array; 

get_ptr_to_msg_seq_for_this_class; 

traverse_this_msg_seq_f or_msg_id_where_class_is_RECEIVER; 
if (message .not .found) 

flag.usecase. as. INCORRECT ; 
break; 

} 

break; 

case CONSTRAINT : 
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display_coiistraint_to_the_user; 

"t ak©_ input _froiii_'the_user_and_store_as_'testcase j 
break ; 

} 

switch (mess age -> postcondiion) 
case RECD.MSG : 

■c 

seaxch_receiv6r_class_name_in_class_array; 
get_ptr_to_msg_seq_for_this_class; 
traverse_this_iasg_seq_f or_msg_id_as_in_RECD_MSG; 
if (message.not .found) 

{ 

f lag_usecase_as_INCORRECT ; 
break; 

} 

else 

{ 

check_usecase_id_of_this_found_msg; 
check_status_flag_of _that_usecase; 

sw it ch C St atus.f lag) 

-c 

case CORRECT : 

usecaselis.correct ; 
break; 

case INCORRECT : 

f lag_usecase_as_INCORRECT : 
break; 
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case BEING.CHECKED : 

check.f or_f ouiid_msg_ in.thi s.usecase ; 
if (f oimd) 
break ; 
else 

flag_usecase_ as. INCOBRECT ; 
break; 

case UNINITIALIZED ; 
traverse.usecaseO ; 
break; 

} 

} . 

break: 

} 

case RECD.RESULTOF.MSG : 

■C 

search.receiver.class.name.in.class.array; 
get_ptr_to_msg_seq_f or.this.class; 
extract _msd_id_from_RECD_RESULTOF_MSG; 

traverse.this.msg.seq.f or_msg_id_as_iii_RECD_RESULTOF_MSG; 
if (message.not .found) 

{ 

f lag_usecase_as_INCORRECT ; 
break; 

} 

else 

{ 

check.usecase.id.of .this.found.msg; 
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clxeck_f 0Tmd_fflSg_ia_'‘isecase ’* 

if Cfomd) 
t>reak; 
else 

f lag_usecase_as_INCORRECT ; 

break; 

> 

> 

break; 


case D0NE_SUB_PR0CESS ; 

searck.receiver.class.naiae.in.class.array. 

6eb>ptr.to_msg.seq_for_this.class, 

traverse.tbis.msg_seq.for.ms6,id.where.class.x . 

if Ciftessage_Bot_f ound) 

i 

f lag_usecase_as_INCORRECT ; 

break; 

> 

break; 


case constraint : 


display_constraiiit_to_tbe_user, 

take.input.from_tbe_user_aiid_store_ 

break; 


as_testcase 


> 


receiver 
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} 

starting.message » stea:tittg_me8sage -> next; 


> 

} 

} 
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Appendix B 

Example of DO A A office 
automation 




CLASS : PERSON 

TYPE : ABSTRACT 

INHERITS : PERSON 

GENERALISATION OF : STUDENT, FACULTY.MEMBER 

ATTR : name <STRING>, 

email_addr <STRING>, 
address <STRING> 


# 

CLASS : STUDENT 
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type : ABSTRACT 


INHERITS : PERSON 

generalisation of : UG.STUDENT, PG.STUDENT 

ATTR : roll.no <NUMBER>, 
address <STRING>, 

joining.date <DATE>, #date of joining the institute 
semester < NUMBER > # Academic semester for student 

RELATED WITH : COURSE (takes, N) , 

PERFORMANCE.RECORD (has, 1) 


g 

CLASS : UG.STUDENT 

INHERITS : STUDENT 


ATTR : acad.status < STRING > # regular/warning/probation etc 
RELATED WITH : DUGC (CONVENER, 1) 



CLASS ; PG.STUDENT 

TYPE : ABSTRACT 

INHERITS ; STUDENT 
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5ENERALISATI0N OF : MTECH.STUDENT . PHD.STODENT 


iTTR : leave.status <{ casual.leaves <NUMBER>, sick.leaves <NUMBER>, 

vacation.leaves <NTJMBER> }> 


ZLkSS : MTECH.STUDENT 

INHERITS : PG.STUDENT 

'lELATED WITH : DPGC (CONVENER, 1) , 

THESIS.SUPERVISOR (Th.guide, 1), 
TA.SIPERVISOR (Ta.instr, 1) 


# - 

CLASS : PHD.STODENT 

INHERITS : PG.STUDENT 

RELATED WITH : DPGC (CONVENER. 1), 

THESIS.SUPERVISOR (Th.guide, 1), 
PHD.ACAD.DETAILS (acad.details, 1) 


# 

CLASS : PHD.ACAD.DETAILS 


ATTR : seminars.giveix <TABLE [ "typ® '<STRING>, title <STRING>, date <DATE> 
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If 

CLASS : PERFORMANCE.RECORD 

ATTR : semester <NUMBER>, 
year <NUMBER>, 
cpi< NUMBER>, 
spi< NUMBER>, 
text<STRING>, 

grades < TABLE [ c_no<NUMBER>,miits<MUMBER>,grade<NUMBER>] > 


# 

CLASS : REG.FORH 

ATTR : year< NUMBER>, 
sem< NUMBER>, 
roll_ixo< NUMBER>, 
room_no < STRING > , 
student _name<STRING> , 

Thesis_superviser<STRING> , 

Financial. Asst <STRING>, 

DPGC.sign<STRING> , 

DUGC.sign <STRING> , 

courses < TABLE [ course.no <NUMBEIR> , c.name <STRING> , 

units <NUMBER>, instructor <STRING> ] > 


« 

CLASS : FACULTY.MEMBER 
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INHERITS : PERSON 


GENERALISATION OF : COURSE.COORDINATOR, CONVENER, DOAA 
ATTR : pf_iio <NUMBER>, 

leave.status <{ casual.l eaves <NUMBER>, <NUMBER 

vacation_leaves <NUMBER>}> 


CLASS : COURSE 


ATTR 


c.no <NUMBER>, 
c_name <STRING>, 
units^pg <NUMBER>, 
un it s _iig <NUMBER> , 
syllabus <STRING>, 
references. <STRING> , 
approval_date <DATE> , 
lab <NUMBER>, 
lecture <NUMBER>, 


tutorial <NUMBER> , 

course.slots < TABLE [ time_slot<NUMBER>,da-y^^'^^^^^ 


room_no<STRING>] 


RELATED WITH : COURSE.COORDINATOR (taught _by, N) , 
STUDENT (enrolled.by, N) 




CLASS : COURSE.COORDINATOR 


INHERITS ; FACULTY.MEMBER 
RELATED WITH : COURSE (teaches, N) 

# 

CLASS : CONVENER 

TYPE ; ABSTRACT 

GENERALISATION OF : DPGC, DUGC 
RELATED WITH : RULE.BOOK (Rules.store, 1) 

« 

CLASS : DPGC 

INHERITS : CONVENER 

# ; 

CLASS : DUGC 

INHERITS : CONVENER 

# 

CLASS : DOAA 
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INHERITS : FACULTY.MEMBER 


RELATED WITH : DPGC (DPGC, 1), 

DUGC (DUGC, 1), 

RULE_BOOK (Rules_store, 1) 


#- 


CLASS : NOTICE.BOARD 

AGGREGATION OF : NOTICE (N) 

« 

CLASS : NOTICE 

ATTR : date <DATE>, 

issued_by <STRING>, 
title <STRING>, 
text < STRING> 


« 

CLASS : RULE.BOOK 

RELATED WITH : RULE (has, N) 

# 

CLASS : RULE 
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ATTR : nile.id <STRING>, 
w.e_f <DATE>, 
eff^Tipto <DATE>, 
rule_fiinc <STRING> 




CLASS : TIME-TABLE 

ATTR : time-table < TABLE [ c.no <NUMBER>, Instructor <STRING>, schedule 

<TABLE C day <STRING> , time, slot <NUMBER>] > ] > 

RELATED WITH : DEPARTMENT ( Belongs_to , 1) 

« 

CLASS : DEGREE 

ATTR : degree-name <STRING>, 

description <STRING> 

RELATED WITH : DEPARTMENT (OfferedBy, M-M) , 

CERTIFICATE (certificate, 1) 


» 

CLASS : LEAVE-FORM 

GENERALISATION OF : STDENT-LEAVE-FORM, FACULTY.LEAVE.FORM 
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ATTR 

# 

CLASS 

INHERITS 

ATTR 


# 

CLASS 

INHERITS 

ATTR 


from <DATE>, 
to <DATE>. 

type_of_leave <STRING> 


: STUDENT.LEAVE.FORM 
: LEAVE.FORM 


roll_no_of _stud <NUMBER> , 
name_of_stud <STRING>, 
stud.sign <STRING>, 
ta_supervisor_sign <STRING>, 
thesis_supervisor_sign <STRING> 


: FACULTY.LEAVE.FORM 

: LEAVE.FORM 


pf_no <NUMBER>, 
name <STRING>, 
sign <STRING> 


# 


CLASS 


: DEPARTMENT 


RELATED WITH : 

STUDENT ( Has , 1-N) , 
FACULTY CHas , M-N) , 
NOTICE.BOARD ( Has , 1-1) , 
TIME_TABLE (Has. 1-1) 


# 

CLASS : ACCOUNTS.SECTIOM 

INHERITS : GENERAL.ADMINISTRATOR 

# 

CLASS : HALL.OFFICE 

% 

INHERITS : GENERAL. ADMINISTRATOR 

# 

CLASS : CALENDER 


ATTR : calender <TABLE [ date <DATE>, <event <STRING>, 

semester <STRING>] >, 
current.sem <NUMBER>, 
current .year <NUMBER> 


# 
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CLASS : PERSON.INTERFACE 


TYPE : INTERFACE 

MENU ITEMS : 

•C ID : "calender" 

NAME : "See Calender" 

ACTION : SEND MESSAGE display_calender OF queries 

}, 

{ ID : "notice" 

NAME : "See Notice Board" 

ACTION ; SEND MESSAGE display .notices OF queries 

}. 

{ ID : "student .details" 

NAME : "Show details" 

ACTION : SEND MESSAGE give.details OF queries 
DESCRIPTION : "Shows the given student’s details that are not 
restricted by the student" 

} 


# 


CLASS 

: STUDENT. INTERFACE 

TYPE 

; INTERFACE 

INHERITS : 

PERSON.INTERFACE 

MENU ITEMS 

. 


■C ID : "register" 

NAME : "Registration" 
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ACTION : INVOKE_MENU [ "register/pay_hall_dues" , 

"register/pay.instt.dues" , 
"register/get_reg_f orm" , 

, "register/fill_reg_form", 

"register/send_reg_form" 

] 

}, 

{ ID : "leaves" 

NAME : "Leaves" 

ACTION : INVOKE_MENU [ "leaves/get_leave_f orm" , 

"leaves/f ill_leave_f orm" , 
"leaves/send_leave_f orm" 

] 

>. 

{ ID : "add.drop" 

NAME : "Add / Drop Courses" 

ACTION : INVOKE.MENU [ "add_drop/get_add.drop_form" , 

"add_drop/f ill.add_drop_f orm" , 
"add.drop/ submit_add_drop_form"3 

)■. 

{ ID : "register/pay_hall_dues" 

NAME : "pay Hall dues" 

ACTION : SEND MESSAGE pay.hall.dues OF Registration 

}. 

i ID : "register/pay.instt^dues" 

NAME : "pay Institute dues" 

ACTION : SEND MESSAGE pay_instt_dues OF Registration 

>. 

{ ID : "register/get.reg.fprm" 

NAME : "Get Regestration Form" 

ACTION : SEND MESSAGE get_reg_form OF Regestration.process 
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}. 

{ ID : "register/f ill_reg_fonB" 

NAME : "Fill Regestration Form" 

ACTION : SEND MESSAGE display.method.f ill.reg.f orm OF 
Regest rat ioE_proces s 

}. 

{ ID : "register/send_reg_form" 

NAME : "Submit Regestration Form" 

ACTION : SEND MESSAGE submit.f illed.reg.form OF 
Regestration.process 

}. 

{ID': "add_drop/get_add_drop_form" 

NAME : "Get Add Drop Form" 

ACTION : SEND MESSAGE get_add_drop_form OF Add_Drop_process 

>, 

{ ID : "add_drop/fill_add_drop_form" 

NAME : "Fill Add/Drop Form" 

ACTION : SEND MESSAGE display _method_fill_add_drop_form OF 
f ill_add_drop_form_process 

}. 

{ ID : "add_drop/submit_add_drop_form" 

NAME : "Submit Add Drop Form" 

ACTION : SEND MESSAGE send_add_drop_form OF add_drop_process 

}, 

{ ID : "leaves/get_leave_form" 

NAME : "Get Leave Form" 

ACTION : SEND MESSAGE give_leave_form OF Leave.processing 

>, 

{ ID : "leaves/f ill_leave_form" 

NAME : "Fill the Leave Form" 

ACTION : SEND MESSAGE f ill_leave_form OF Leave_processing 
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} 

DISPLAY METHODS : 

MENU DISPLAY : VERTICAL 

RELATED WITH : A_D_FORM_INTERFACE (uses, 1-1), 

STUDENT (attached_to, 1-1) 


# 

CLASS : REG_FORM_INTERFACE 

TYPE : INTERFACE 


MENU ITEMS : 

•C ID : "store" 

NAME : "store this reg form" 

ACTION.: SEND MESSAGE store_reg_form 

} 

FILLIN ITEMS : 

{ ID : "year" 

NAME : "Year" 

CONSTR : TYPE = < NUMBER> 

}. 

{ ID : "sem" 

NAME : "Semester" 

CONSTR : TYPE = <NUMBER> 

}. 

{ ID : "roll.no" 
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NAME : "Roll Number" 

CONSTR : TYPE = < NUMBER> 

}. 

{ ID : "room.no" 

NAME : "Room Number" 

CONSTR : TYPE = < STRING > 

}. 

{ ID : "student .NAME" 

NAME : "Name in Block letters" 

CONSTR : TYPE » <STRING> 

}, 

•C ID : "fin.asst" 

NAME : "Financial.Asst" 

CONSTR : TYPE = <STRING> 

>. 

■C ID : "th_sup" 

NAME : "Thesis.superviser" 

CONSTR : TYPE = <STRING> 

>. 

{ ID : "convener.sign" 

NAME : "Signature OF the Convener (DPGC / DUGC) " 
CONSTR : TYPE = <STRING> 

>, 

{ ID : "course.no" 

NAME : "Course Ntimber" 

CONSTR : TYPE = <STRING> 

}. 

{ ID : "c_NAME" 

NAME : "Course Name" 

CONSTR : TYPE = <STRING> 

}. 
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{ ID : "units" 

NAME : "No OF Units" 

CONSTR : TYPE = <NUMBER> 

>. 

{ ID : "instr" 

NAME : "Initials OF Instructor" 

CONSTR : TYPE * <STRING> 

>. 

{ ID : "courses" 

NAME : "Courses to register" 

CONSTR : TYPE = < TABLE [ course_no<NUMBER> , 
c_NAME<STRING> , unit s<NUMBER> , 
instructor<STRING> ] > 

} 

DISPLAY METHODS : 

FILLIN DISPLAY { # This is to fill the Regestration form 

"Regestration Form" 

<FILLIN ITEMS : year, sem> 

<FILLIN ITEMS : naine> 

<FILLIN ITEMS : roll_no> 

<FILLIN ITEMS : room_no> 

<FILLIN ITEMS : courses > 

} . 


« 

CLASS : . DOAA.INTERFACE 
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TYPE 


INTERFACE 


INHERITS : FACULTY.MEMBER.INTERFACE 


MENU ITEMS : { ID : "regestration" 

NAME : "Regestration related" 

ACTION : INVOKE_MENU [ "regestration/send_reg_forms" ] 

}. 


{ ID : "grades" 

NAME : "Grades processing" 

ACTION : INVOKE_MENU [ "grades/prepare_grade_sheets" , 

"grades/send_grade_sheets_to,depts" ] 

}, 


{ ID : "degree_award" 

NAME : "degree Awarding" 

ACTION : INVOKE_MENU [ "degree_award/clieck_for_deg_prereq" ] 

>. 

{ ID : "regestration/send_reg_forms" 

NAME : "Send Regestration forms to DPGCs, DUGCs" 
ACTION : SEND MESSAGE send_reg_f orms_to_cdgcs OF 
Regestr at i on_proces s 


}. 

{ ID : "grades/prepare_grade_sheets" 

NAME : "Prepare Student's Grade Sheets" 

ACTION : SEND MESSAGE prepare_grade_ sheets OF Evaluation_process 


)■, 

{ ID : "grades/send_grade_sheets_to_depts" 

NAME ; "Send Student’s Grade Sheets to their Depts" 
ACTION : SEND MESSAGE students_gr‘ade_sheets OF 
Evaluation_process 
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}, 

{ ID : "send.notice" 

NAME : "Send a Notice" 

ACTION : DO SUB_PROCESS di splay ^laet hod 

} . 


» 

CLASS : C0URSE_C00RD_ INTERFACE 

TYPE : INTERFACE 

MENU ITEMS : 

{ ID : "courses" 

^ NAME : "Courses Menu" 

ACTION : INVOKE.MENU ["general/get_registered_students"] 

}. 

{ ID : "courses/give_grades" 

NAME : "Give grades to registered students" 

ACTION : DO SUB.PROCESS take_input_course_number; 

SEND MESSAGE give_registered_students OF 
Evaluation ; 

DO SUB.PROCESS display _method_give_grades 

} 


FILLIN ITEMS : { ID : "student" 
NAME : "Student Name" 

CONSTR : TYPE » <STRING> 

}. 

i ID : "roll.no" 

NAME : "Roll number" 
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CONSTR : TYPE = <NUMBER> 

}, 

{ ID : "grade" 

NAME : "Grade" 

CONSTR : TYPE * <CHAR> VALUE = [A-F] 

}. 

{ ID : "grade.list" 

NAME : "List OF Student Grades" 

CONSTR : TYPE * < TABLE [student<STRING>, roll.no 
<NUMBER>, grade_given<CHAR>]> 

} 


DISPLAY METHODS : 

MENU DISPLAY : VERTICAL 

# # 

CLASS : NOTICE_INTERFACE 
TYPE : INTERFACE 

FILLIN ITEMS : { ID : "title" 

NAME : "Title OF the Notice" 

CONSTR : TYPE = <STRING> 

ATTACHED.TO : NOTICE 

}. 

{ ID : "to" 

NAME : "To" 

CONSTR : "TYPE = <STRING> 

ATTACHED.TO : NOTICE 

}, 

{ ID : "timestamp" 

NAME : "Dated" 
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CONSTR : TYPE = <DATE> 
ATTACHED.TO : NOTICE 

}. 

{ ID : "issuedby" 

NAME : "Issued by" 

CONSTR ; TYPE » <STRING> 
ATTACHED.TO : NOTICE 

}, 

{ ID : "text" 

NAME : "Text OF the Notice" 
CONSTR : TYPE = <STRING> 
ATTACHED.TO : NOTICE 
} , 


RELATED WITH : NOTICE (notice, 1) 

# 

GENERIC PROCESS ; : make.notice 
INPUTS : ISSUEE 


» # 

FROM : ISSUE 

TO : NOTICE. INTERFACE 

MSG.ID : make.notice () 

RESULT : res.notice <NOTICE> 

FROM : NOTICE.INTERFACE 

TO : ISSUE 

MSG.ID : replyto.make.notice (notice <NOTICE>) 

MSG.TYPE : reply 
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MSG.ID 


: extract .details (query » "roll.no" <STRING>, reg_form 

<REGESTRATION_FORM» 

# extract.details should be taken as a general purpose message 
RESULT : roll.no <NUMBER> 


FROM 

TO 

MSG.ID 

RESULT 


DOAA' 

HALL.OFFICE 

check. student _for_dues (roll.no <NUMBER>) 
payed <BOOLEAN> 


IF (payed TRUE) { 

FROM : DOAA 

TO : ACCOUNT.SECTION 

MSG.ID' : check.student. lor .dues (roll.no <MUMBER>) 

RESULT : payed.instt.dues <B00LEAN> 


IF (payed.instt.dues == TRUE) { 


FROM : DOAA 

TO : DOAA 

MSG.ID : form.links () 

ACTION : DO SUB.PROCESS form.assoc.between.stud.course 

( reg.form <REGESTRATION_FORM>) 

} ELSE { 


FROM : DOAA 

TO : STUDENT (BACK) 

MSG.ID : replyto.req.for.reg (remark = "Instt dues not paid" 

<STRING>) 
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MSG_TYPE : reply 


} 

} ELSE { 

FROM : DOAA 

TO : STUDENT (BACK) 

MSG_ID : replyto_req_for_reg (remark » "Hall duejs not paid" <STRING>) 
MSG.TYPE : reply 

} 

# # 

SUB_PROCESS : : form_association_between_student_course 
# # 

FROM : DOAA 

TO : DOAA 

MSG_ID : extract .details (query = "roll.no, courses" <STRING>, 

reg_form <REGESTRATION_FORM>) 

RESULT : res {roll.no <NUMBER>, courses <TABLE [c_no <STRING>, c.name <STRING 

units <NUMBER>, instructor <STRIMG>]>} 

FOREACH c_no (courses) { 

FROM : DOAA 

TO : COURSE (c_no == COURSE: :c_no) 

MSG.ID : give.handle () 

MSG.TYPE : shared 
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RESULT 

: course.ref <HANDLE> 

FROM 

: DOAA 

TO 

: STUDENT <roll.no *= STUDENT: :roll_no) 

MSG.ID 

: give .handle () 

MSG.TYPE 

: shared # for security 

RESULT 

: student .ref <HANDLE> 


# Here comes the necessity for the design to have an idea about the 

# implementation platform 

#.For the above cause (of forming association between students cind 

# courses), if we ar^ ultimately going to build the application over 

# C++, above specification will be OK But if we are going to build on 

# ORACLE, then it may not look proper as in oracle there is no concept 

# of references 


FROM 

TO 

MSG.ID 

MSG_TYPE 


DOAA 

STUDENT (roll_no == STUDENT: :roll_no) 
form_a5soc_with_course (course.ref <REFERENCE>) 
exclusive 


FROM 

TO 

MSG.ID 

MSG.TYPE 


DOAA 

COURSE (c_no == COURSE: :c_no) 

form_assoc_with_student (student_ref <REFERENCE>) 
exclusive 


} 


# 


# 
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SUB_PROCESS : ; cliaiige_the_reg_f orm 

# # 

FROM : STUDENT 

TO ; STUDENT 

MSG.ID : retrive.reg.fom ( constraints <STRING> ) 

RESULT ; reg_form <REG_FORM> 

ACTION : SEND MESSAGE modify.attr 

FROM : STUDENT 

TO : STUDENT 

MSG_ID : modify.attr ( reg_form <REG_F0RM>, 

values.string <STRING> ) 

g « 

SUB.PROCESS : ; check_and_sign_reg_f orm 
# # 

FROM : CONVENER 

TO : CONVENER 

MSG.ID : check_reg_f orm (reg.form <REGESTRATION_FORM>) 

RESULT : correct <BOOLEAN> 

IF (correct == FALSE) { 

FROM : CONVENER 

TO : STUDENT (BACK) 

MSG.ID : replyt6_sign_reg_form (remarks = "Incorrect" <STRING>) 


MSG.TYPE : reply 

* 
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> ELSE { 


FROM : CONVENER 

TO : REGESTRATION.FORM 

MSG.ID : put_dpgc_sign (signature <SIGNATURE>) 

MSG.TYPE : exclusive 

} 

# # 

SUB.PROCESS : : check_eligibility_f or.reg 

# # 

FROM : CONVENER 

TO : CONVENER 

MSG_ID : check_for_reg_notice () 

RESULT : present <BOOLEAN> 

IF (RECEIVED reg_notice OF.Regestration) { 

FROM : CONVENER 

TO : STUDENT (BACK) 

MSG.ID : give.details (str = " status, desgn" <STRING>) 

RESULT : details <STRING> 

FROM : STUDENT 

TO : CONVENER (BACK) 

MSG.ID : replyto_give_details (details <STRING>) 
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FROM 

TO 

MSG.ID 

RESULT 


CONVENER 

RULE.BOOK 

give.rule (str«"reg_elig_check_rule" <STRING>, desgn <STRING>) 
rule <RULE> 


FROM 

TO 

MSG.ID 

RESULT 


CONVENER 

CONVENER 

apply .rule (rule <RULE>, details <STRING>) 
eligibile <B00LEAN> 


IF (eligible == TRUE) { 


FROM 

TO 

MSG.ID 

RESULT 


CONVENER 

CONVENER 

create.reg.form () 
reg.form <REGESTRATION.FORM> 


FROM 

TO 

MSG.ID 

MSG.TYPE 

ACTION 


CONVENER 
STUDENT (BACK) 

replyto.req_for.reg.form ( reg_form <REGESTRATION_FORM>, 
remarks = "Eligible for Regestration" <STRING> ) 

reply 

DO SUB.PROCESS store (reg.form <REGESTRATION_FORM>) , 

DO SUB.PROCESS store.temp (remarks <STRING>) 


} ELSE { # eligible is FALSE 

FROM : CONVENER 

TO : STUDENT (BACK) 

MSG.ID : replyto.req.for.reg.form (reg.form <REGESTRATION_FORM>, 
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remarks = "Not eligible for regestration" <STRING>) 
# reg_form will be NULL 

MSG.TYPE : reply 

ACTION : DO SUB^PROCESS store (reg.form <REGESTRATION_FORM>) , 

DO SUB_PROCESS store.temp (ranarks <STRING>) 


} ELSE { # Regestration notice has not been received from DOAA 
# means it is not yet time for regestration 


FROM 

TO 

MSG.ID 

MSG.TYPE 

ACTION 


CONVENER 
STUDENT • (BACK) 

replyto.req.for.reg.form (reg.form <REGESTRATION_FORM>, 
remarks = "not time for regestration" <STRING>) 

reply 

DO SUB.PROCESS store (reg.form <REGESTRATION.FORM>) , 

DO SUB.PROCESS store.temp (remarks <STRING>) 


} 

« * * # 

« 

SUB.PROCESS : : prepare.studs.grade.sheets 
« # 

# check_whether_all_grades_received checks whether DOAA has received grades 

# from all course coordinators 
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FROM : DOAA 

TO : DOAA 

MSG_ID : ch.eck_wheth.er_all_grades_received ( ) 

» » 

RESULT : res •{ all_courses_received <BOOLEAN>, course_grades_not .received 

<TABLE[c_iio <NUMBER>]> > 

IF (all_courses_received == TRUE)' { 

FROM : DOAA 

TO : RULE.BOOK 

MSG.ID : give.rule ( query.str <STRING> ) 

MSG.COND (all_courses_received == TRUE) 

RESULT : cpi_compute_rule <RULE> 

FROM : DOAA 

TO : DOAA 

MSG.ID : retreive_grade_lists() 

RESULT : stud_grade_list < TABLE [ stud.name <STRING>, 

roll.no <NUMBER>, grade <CHAR>]> 

DOAA. 

DOAA 

create. stud_grade_sheets (st'ud.grade.list < TABLE 
C stud.name <STRING>, roll.no <NUMBER>, 
grade <CHAR>]> ) 

: stiid.grade. sheet <TABLE [c.no <STRING>, 

c.name<STRING> , units <NUMBER>, grade <CHARACTER>]> 

: RECEIVED RESULTOF retreive.grade_lists 

FROM : DOAA 


FROM 

TO 

MSG.ID 


RESULT 

PRE_COND 
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TO 

MSG.ID 


RESULT 


PRE_COND 

FROM 

TO 

MSG.ID 

RESULT 

PRE_CQND 

FROM 

TO 

MSG.ID 

MSG.TYPE 

FROM 

TO 

MSG.ID 

PRE_COND 

RESULT 

FROM 

TO 

MSG.ID 


: DOAA 

: compute.cpi ( cpi.compute.rule <RULE>, 
stud.grade.sheet <TABLE [c.no <STRING>, 
c.name <STRING>, units <NUMBER>, grade <CHARACTER>]>) 
: res {stud.grade_sheet <TABLE [c.no <STRING>, 
c.name <STRING>, units <NUMBER>, 
grade <CHARACTER> ] >, stud.cpi <NUMBER> } 

: RECEIVED RESULTOF create. stud.grade.sheet s 

: DOAA 
: RULE.BOOK 

: give.rule ( query.str <STRING> ) 

: status.eval.rule <RULE> 

: RECEIVED RESULTOF compute.cpi 

: RULE.BOOK 
: DOAA ( BACK) 

: replyto.give.rule (status.eval.rule <RULE>) 

: reply 

: DOAA 
: DOAA 

: compute. student.status ( stud.details <STRING>, 

status.eval.rule <RULE> ) 

: RECEIVED replyto.give.rule 
: student.status <STRING> 

: DOAA 
: DOAA 

: add.staus.to.grade.sheet (student.status <STRING>, 

stud.grade.sheet ) 
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PRE_COND : RECEIVED RESULTOF compute_stiident_status 

} ELSE -C # all.couses^received == FALSE 

FROM : DOAA 

TO : DpAA_INTERFACE 

MSG.ID : replyto_prepare_grade_sheets (remarks <STRING>, 

course_grades_not_received <TABLE[c_no <STRING>]>) 

# remarks = "Following course_coordinators have not 

# send grade lists" 

MSG.TYPE : reply 


FOREACH course. 

.no (course_grades_not_received) { 

FROM 

DOAA 

TO 

COURSE (COURSE: :c_no == $l”course_no) 

MSG.ID 

inform_instructors_to_send_grades 
(msg_str = "Please send grades" <STRIMG>) 

. # "instructors" should be the name of the relation 

# (declared in "RELATED WITH" field of COURSE class) 

# with which the COURSE knows its co-ordinator 


FROM 

; COURSE 

TO 

: C0URSE_C00RDINAT0R (ALL.RELATED) 

MSG.ID 

: urgent .mess age (msg.str - "Please send grades' 

. <STRING>) 

PRE_C0ND 

: RECEIVED urgent.message 

FROM 

: C0URSE.C00RDINAT0R 

TO 

: COURSE.COORD. INTERFACE 
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} 

} 

SUB_PROCESS 

# 

FROM : 

TO : 

MSG.ID ; 

RESULT 

FROM : 

TO : 

MSG.ID : 

MSG.TYPE : 

ACTION _ : 

FROM : 

TO ; 

MSG.ID : 

PRE_COND ; 

RESULT : 

FROM : 

TO : 


MSG_ID : urgent_message (msg.str <STRING>) 

PRE_COND : RECEIVED info]nn_instructors_to_s6nd_grades 


: : get_student_details 
# 


COURSE 

STUDENT (ALL.RELATED) # All STUDENT objects Related to this 

# COURSE object 

give.details ($Evaluation_process !give_registered_ students ! query <ST 
res {name <STRING>, roll.no <NUMBER>} 

STUDENT 
COURSE ( BACK) 

replyto.give.details ($name <STRING>, $roll_no <NUMBER>) 
reply 

SEND MESSAGE build.student.details.table 

COURSE 

COURSE 

build.stud.details.table 

($give_details=name <STRING>, $give_details=roll_no <NUMBER>) 
RECEIVED RESULTOF give.details 

registered. students <TABLE [name <STRING>, roll.no <NUMBER>]> 


COURSE 

COURSE 
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MSG_ID : clieck_whether_all_details_received () 

RESULT : all_details_receiv6d <BOOLEAN> 

IF (all_details_reeived == TRUE) { 

FROM : COURSE 

TO : COURSE_COORDINATOR (BACK) 

MSG_ID : replyto_send_registered_students 

( registered. students < TABLE [ student <STRING>, 
roll_no<NUMBER>] >) 

MSG.TYPE : reply 

} 

SUB.PROCESS : : get_details_from_student 
# # 

FROM : DOAA 
TO : STUDENT 

MSG.ID : give_cpi_spi() 

ACTION : SEND MESSAGE give.details 
RESULT : res{cpi<NUMBER>, spi<NUMBER>} 


FROM 

: STUDENT 

TO 

: PERFORMANCE_RECORD 

MSG.ID 

: give_details() 

RESULT 

: res-Ccpi<NUMBER>,spi<NUMBER>> 

FROM 

: STUDENT 
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TO 


: DOAA 


MSG.ID : replyto_give_cpi_spi ( cpi<NUMBER>, spi<NUMBER> ) 
MSG.TYPE: reply 


SUB_PROCESS : : check. student _for_waniing 


# # 

FROM : DOAA 

TO : DOAA 

MSG.ID : check_for_warning ( cpi<NUMBER>, spi<NUMBER> ) 

PRE.COND: SPI < "2.0" kk SPI <= "4.5" I I CPI >= "5.0" 

ACTION : SEND MESSAGE give_warning_message OF check_student_for_waming 


FROM : DOAA 
TO : STUDENT 

MSG.ID : give_warning_message( remarks = " YOU ARE ON WARNING" < STRING> ) 

SUB.PROCESS : : check_student_on_acad_prob 
# # 

FROM : DOAA 
TO : DOAA 

MSG.ID : check_student_for_acad_prob ( cpi<NUMBER>, spi<NUMBER> ) 
PRE_COND: SPI < "4.5" kk CPI < "5.0" 

ACTION : SEND MESSAGE give_acad_prob_msg OF check_student_on_acad_prob 

FROM : DOAA 
TO : STUDENT 

MSG.ID : give_acad_prob_msg( remarks = "YOU ARE ON ACAD_PROB"<STRING>) 
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SUB_PROCESS : : check.f or.dismissal 


if if 

FROM : DOAA 
TO : DOAA 


MSG_ID : ch.eck_stiideiit_for_dismissal() 

PRE_COND: SPI <= "2.0" && CPI < "4.5" 

ACTION : SEND MESSAGE give_dismissal_message OF check.f or_dismissal 

FROM : DOAA 
TO : STUDENT 

MSG_ID : give_dismissal_message( remarks =" YOU ARE DISMISSED" <STRING>) 
PROCESS : : Regestration.process 


# # 

FROM : DO AA_ INTERFACE 

TO : DOAA 

MSG_ID : prepare_reg_n.otice () 

ACTION : DO GENERIC SUB_PROCESS make.notice #{ISSUEE : $T0, 

#res_message : reg_notice} 

RESULT : reg.notice <NOTICE> 

FROM : DOAA.INTERFACE 

TO : DOAA 

MSG_ID : send_reg_notice_to_depts (reg.notice <NOTICE>) 

PRE^COND : RECEIVED RESULTOF prepare_reg_notice 

ACTION : SEND MESSAGE notice.for.regestration 

FROM : DOAA 
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TO 

MSG.ID 

ACTION 

FROM 

TO 

MSG_ID 

ACTION 

FROM 

TO 

MSG.ID 

RESULT 

ACTION 

# sending 

# derived 

FROM 

TO 

MSG.ID 

MSG.TYPE 

FROM 

TO 

MSG.ID 

RESULT 

ACTION 


FROM 


: CONVENER (ALL) 

: notice.for.regestration (reg.notice <N0TICE>) 

: DO SUB.PROCESS store.notice 

: STUDENT.INTERFACE 
: STUDENT 
: get.reg.form () 

: SEND MESSAGE req.for.reg.form #{FR0M: STUDENT, TO: CONVENER} 

: STUDENT 
: CONVENER 

; req.for.reg_f orm () 

: res.val {reg.form <REGESTRATION.FORM> , remarks <STRING>} 

: DO SUB.PROCESS check.eligibility.for.reg 

message to abstract class ^CONVENER' means sending to one of the 
classes 

: STUDENT 

: REGESTRATION.FORM 
: fill.form (values <STRING>) 

: exclusive # this type takes care of security 

: STUDENT 
: CONVENER 

: sign.reg.f orm (reg.form <REGESTRATION_FORM>) 

: reg.form <REGESTRATION.FORM> # signed regestration form 
: DO SUB.PROCESS check.and.sign.reg.f orm 

(reg.form <REGESTRATION.FORM>) 


: STUDENT 
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TO : DOAA 

MSG.ID : req.for.reg (reg.form <REGESTRATION_FORM>) 

RESULT : remarks <STRING> 

ACTION : DO SUB.PROCESS process_tlie_reg_form 

# # 

PROCESS : : Evaluation.process 
# # 


#• course coordinator gets the students list for the course he teaches 


FROM 

TO 

MSG.ID 

RESULT 

ACTION 


COURSE.COORD.INTERFACE 

COURSE.COQRDINATOR 

get.registered.students ( course.no <STRING>) 

registered.students <TABLE [student <STRING>, roll.no <NUMBER>]> 
SEND MESSAGE give.registered. students 


FROM 

TO 

MSG.ID 

RESULT 

PRE.C0ND 

ACTION 


COURSE.COORDINATOR 
COURSE (c.no == course.no) 

give. registered.students ( query = "name, roll. no" <STRING> ) 
registered.students < TABLE [ student <STRING>, roll.no <NUMBER>]> 
RECEIVED get.registered.students 

DO SUB.PROCESS get. student .details (query <STRING>) 


# The semantics of these kind of TO constraints is first check among 

# the relatives whether a relation satisfying this constraint exists, if 

# no, then send the message to class, which will resolve the constraint and 

# send message to corresponding object (s) 

FROM : COURSE.COORDINATOR 

TO : COURSE.COOTD. INTERFACE ( BACK) 
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MSG_ID 


MSG.TYPE 

FROM 

TO 

MSG.ID 

MSG.TYPE 

ACTION 

FROM 

TO 

MSG.ID 


POST.COND 

ACTION 

FROM 

TO 

MSG.ID 

PRE.COND 

ACTION 

FROM 

TO 

MSG.ID 

ACTION 


: replyto.get .registered. students (registered.students < TABLE [ 

student <STRING>, roll.no<NUMBER>] 


: reply 


COURSE_COORD. INTERFACE 
COURSE.COORDINATOR 

ch.aiige_grade.list ( grade.list <TABLE 

[ student <STRING>, roll.no <NUMBER>, grade <CHARACTER>]>) 
exclusive 

DO SUB.PROCESS store.grade.list 

COURSE.COORD. INTERFACE 
COURSE.COORDINATOR 
send.grade.list.to.doaa ( grade.list 

< TABLE [student <STRING>, stud.rollno <NUMBER>, 
grade <CHAR>]> ) 

: DONE SUB.PROCESS store_grade_list 
: SEND MESSAGE grade.list OF Evaluation.process 

COURSE.COORDINATOR 

DOAA 

grade.list ( grade.list < TABLE [ stud.rollno <NUMBER>, 

grade <CHAR>] >) 

: RECEIVED send_grade_list_to_doaa 
: DO SUB.PROCESS store.grade.list 


DOAA. INTERFACE 
DOAA 

prepare.grade. sheets ( ) 

DO SUB.PROCESS prepare.studs .grade. sheets 
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FROM : DOAA.INTERFACE 

TO : DOAA 

MSG_ID : dispat ch_grade_sheets () 

MSG.TYPE : exclusive 

ACTION : SEND MESSAGE students_grade_sheets 

FROM : DOAA 

TO : DEPARTMENT 

MSG_ID : students_grade_sheets ( grade_sheets <GRADE_SHEET> ) 
PRE_COND : DONE SUB_PROCESS prepare. studs_grade_ sheets 

FROM ; DEPARTMENT 

TO : STUDENT 

MSG_ID : grade.sheet ( grade.sheet <GRADE_SHEET> ) 

ACTION : DO SUB_PROCESS store_grade_sheet 

PRE.COND : RECEIVED students_grade_sheets 

PROCESS:: academic.probation 
# # 

FROM : DOAA 
TO : DOAA 


MSG.ID: get_cpi_spi ( roll.no < NUMBER>) 

ACTION: DO SUB.PROCESS get_details_from_student 
RESULT: res{cpi<NUMBER>,spi<NUMBER>} 

# 

GENERIC MESSAGE : : 

# # 


# Calender queries 
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FROM 

TO 

MSG.ID 

RESULT 

FROM 

TO 

MSG.ID 

RESULT 

FROM 

TO 

MSG.ID 

RESULT 

# Notice queries 

FR'OM 

TO 

MSG.ID 

# constraints can 
RESULT 

# 


: * 

: CALENDER 
: give. calender () 

: calender <CALENDER> 

: * 

: CALENDER 

: give.event (date <DATE>) 

: event <STRING> 

: * 

: CALENDER 

: give.date (event <STRING>) 
: date <DATE> 


: * 

: NOTICE.BOARD 

: give.notice (constraints <STRING>) 
be Mate=xxx' , issued_by=xxx, ALL etc 
: notice <N0TICE> 
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